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ABSTRACT 

Time-of-flight, i.e., the time incurred by a signal to travel 
from transmitter to receiver, is perhaps the most intuitive way 
to measure distances using wireless signals. It is used in ma¬ 
jor positioning systems such as GPS, RADAR, and SONAR. 
However, attempts at using time-of-flight for indoor local¬ 
ization have failed to deliver acceptable accuracy due to fun¬ 
damental limitations in measuring time on Wi-Fi and other 
RF consumer technologies. While the research community 
has developed alternatives for RF-based indoor localization 
that do not require time-of-flight, those approaches have their 
own limitations that hamper their use in practice. In par¬ 
ticular, many existing approaches need receivers with large 
antenna arrays while commercial Wi-Fi nodes have two or 
three antennas. Other systems require fingerprinting the en¬ 
vironment to create signal maps. More fundamentally, none 
of these methods support indoor positioning between a pair 
of Wi-Fi devices without third party support. 

In this paper, we present a set of algorithms that mea¬ 
sure the time-of-flight to sub-nanosecond accuracy on com¬ 
mercial Wi-Fi cards. We implement these algorithms and 
demonstrate a system that achieves accurate device-to- 
device localization, i.e. enables a pair of Wi-Fi devices to 
locate each other without any support from the infrastruc¬ 
ture, not even the location of the access points. 


1. Introduction 


The time-of-flight of a signal captures the time it takes 
to propagate from a transmitter to a receiver. Time-of-flight 
is perhaps the most intuitive method for localization using 
wireless signals. If one can accurately measure the time- 
of-flight from a transmitter, one can compute the transmit¬ 
ter’s distance simply by multiplying the time-of-flight by the 
speed of light. As early as World War I, SONAR systems 
used the time-of-flight of acoustic signals to localize sub¬ 
marines. Today, GPS, the most widely used outdoor localiza¬ 
tion system, localizes a device using the time-of-flight of ra¬ 
dio signals from satellites. However, applying the same con¬ 
cept to indoor localization has proven difficult. Systems for 
localization in indoor spaces are expected to deliver high ac¬ 
curacy (e.g., a meter or less) using consumer-oriented tech¬ 
nologies (e.g., Wi-Fi on one’s cellphone). Unfortunately, 
past work could not measure time-of-flight at such an ac¬ 
curacy on Wi-Fi devices (55}[TO]]. As a result, over the years, 
research on accurate indoor positioning has moved towards 



Figure 1: Chronos on a personal drone: Chronos enables a drone 
to maintain a safe distance d from a user by tracking a device in 
her pocket, while capturing a video in uncalibrated indoor environ¬ 
ments. 


more complex alternatives such as employing large multi¬ 
antenna arrays to compute the angle-of-arrival of the sig¬ 
nal (56] [30) . These new techniques have delivered highly 
accurate indoor localization systems. 

Despite these advances, time-of-flight based localization 
has some of the basic desirable features that state-of-the- 
art indoor localization systems lack. In particular, measur¬ 
ing time-of-flight does not require more than a single an¬ 
tenna on the receiver. In fact, by measuring time-of-flight 
of a signal to just two antennas, a receiver can intersect the 
corresponding distances to locate its source. In other words, 
a receiver can locate a wireless transmitter with no support 
from surrounding infrastructure whatsoever. This is quite un¬ 
like current indoor localization systems, which require the 
help of multiple access points to find the distance between 
a pair of mobile devices. Furthermore, each of these access 
points need to have many antennas - far beyond what is sup¬ 
ported in commercial Wi-Fi devices. In addition, the location 
of these access points has to be calibrated and known a pri¬ 
ori. 

But, why is it that one cannot accurately measure time-of- 
flight on commercial Wi-Fi devices in the first place? In par¬ 
ticular, to achieve state-of-the-art positioning accuracy, one 
must measure time-of-flight at sub-nanosecond granularity. 
However, doing so on commercial Wi-Fi cards is fundamen¬ 
tally challenging for the following three reasons. 

Limited Time Granularity: First, the straightforward ap¬ 
proach to measure time-of-flight is to read off the clock of 
the Wi-Fi radio when the signal arrives (55] . Unfortunately, 
the clocks on today’s Wi-Fi cards operate at tens of Mega- 
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hertz, limiting their resolution in measuring time to tens of 
nanoseconds (T0|[49]|4()). To put this in perspective, a clock 
running at 20 MHz (the bandwidth of typical Wi-Fi systems), 
can only tell apart distances separated by 15 m, making it im¬ 
practical for accurate indoor positioning. Even recent state- 
of-the-art systems that measure time-of-flight using high- 
resolution 88 MHz Wi-Fi clocks (39) and super-resolution 
channel processing techniques (57| suffer a mean localiza¬ 
tion error of about 2.3 m. 


Packet Detection Delay: Second, any measurement of 
time-of-flight of a packet necessarily includes the delay in 
detecting its presence. To make matters worse, this packet 
detection delay is typically orders-of-magnitude higher than 
time-of-flight. For indoor Wi-Fi environments, time-of-flight 
is just a few nanoseconds, while packet detection delay spans 
hundreds of nanoseconds (45j. Today, there is no way to 
tease apart the time-of-flight from this detection delay. 

Multipath: Finally, in indoor environments, signals do 
not experience a single time-of-flight, but a time-of-flight 
spread. To see why, observe that wireless signals in indoor 
environments travel along multiple paths, and bounce off 
walls and furniture. As a result, the receiver obtains sev¬ 
eral copies of the signal, each having experienced a different 
time-of-flight. To perform accurate localization, one must 
therefore be able to disentangle the time-of-flight of the most 
direct path from all the remaining paths. 

In this paper, we show that it is possible to design al¬ 
gorithms that overcome the above limitations and measure 
the time-of-flight at sub-nanosecond accuracy using off-the- 
shelf Wi-Fi cards. At a high level, our approach is based on 
the following observation: If one had a very wideband radio 
(e.g., a few GHz), one could measure time of flight at sub¬ 
nanosecond accuracy. While each Wi-Fi frequency band is 
only tens of Megahertz wide, there are many such bands that 
together span a very wide bandwidth. Our solution therefore 
collects measurements on multiple Wi-Fi frequency bands 
and stitches them together to give the illusion of a wide-band 
radio. Our key contribution is an algorithm that achieves 
this, despite the fact that Wi-Fi frequency bands are non¬ 
contiguous, and in some cases, a few Gigahertz apart. We 
further develop a set of algorithms that build on this idea to 
overcome each of the aforementioned challenges. We also 
detail the benefits and limitations of such a design. 

To demonstrate the performance and practicality of our 
design, we built Chronos, a software-only solution that har¬ 
nesses our algorithms to enable a pair of commercial Wi-Fi 
devices to locate each other without any support from the in¬ 
frastructure. To illustrate its capabilities, we apply Chronos 
to personal drones (43) that follow a user around and cap¬ 
ture videos of their everyday indoors activities. Such drones 
can help monitor fitness, activities and exercise of users at 
home, work or the gym (see Fig. [I}. Chronos allows a per¬ 
sonal drone to maintain the best possible distance relative to 
its user to take optimal videos at the right focus. It achieves 
this by using the Wi-Fi card on the drone to locate the user’s 


device, without any help from the infrastructure. The ap¬ 
plication also illustrates Chronos’s ability to run on stan¬ 
dard 3-antenna Wi-Fi cards, as opposed to large antenna ar¬ 
rays, which would be too heavy and difficult to mount on 
lightweight indoor drones. 

We evaluated Chronos’s performance on pairs of devices 
equipped with Intel 5300 Wi-Fi cards, including Thinkpad 
W530 laptops, as well as an AscTec Atom board (a small 
computing board) mounted on an AscTec Hummingbird 
Quadrotor drone platform. Our results reveal the following: 

• Chronos achieves a median error in time-of-flight of 0.47 
ns in line-of-sight and 0.69 ns in non-line-of-sight set¬ 
tings, corresponding to a physical distance accuracy of 
14.1 cm and 20.7 cm respectively. 

• Chronos uses time-of-flight to triangulate the location of 
the device with a median error of 58 cm in line-of-sight 
and 118 cm in non-line-of-sight settings. 

• When mounted on a drone, Chronos integrates with 
robotic control algorithms to further improve its accuracy. 
It maintains the required distance relative to a user’s de¬ 
vice with a root mean-squared error of 4.2 cm. 

Contributions: To our knowledge, Chronos is the first RF- 
based positioning system that can measure sub-nanosecond 
time of flight on commercial Wi-Fi cards. Chronos leverages 
the time-of-flight measurements to estimate device-to-device 
distance measurements without any infrastructure support. 
Finally, Chronos operates on typical 2/3-antenna Wi-Fi re¬ 
ceivers, yet delivers state-of-the-art localization accuracy. 


2. Related Work 


This paper is closely related to past work that measures 
the time-of-flight of Wi-Fi signals. There have been several 
studies that resolve time-of-flight to around ten nanoseconds 
using the clocks of Wi-Fi cards (55][^[T9||3^. Many con¬ 
clude that the clocks on current Wi-Fi hardware alone cannot 
permit higher resolutions of time-of-flight (T0[ 49 40). Some 
systems have attempted to compensate for the lack of ac¬ 
curate time-of-flight measurements on Wi-Fi radios by aug¬ 
menting their designs with other sensors and hardware. In 
particular, SAIL (39] [ couples time-of-arrival measurements 
on the 88 MHz clock of an Atheros Wi-Fi card with in¬ 
ertial motion sensors on a mobile device. It asks the user 
to physically walk to different locations and couples Wi-Fi 
channel measurements at a single access point with readings 
of motion sensors on their mobile device. SAIL processes 
this information to measure time-of-flight at a granularity 
of several nanoseconds, achieving localization accuracy of 
a few meters. However, unlike Chronos, SAIL requires users 
to physically move to different locations, along restricted 
classes of trajectories, due to its reliance on motion sen¬ 
sors. Synchronicity (57) uses three WARP access points to 
compute the location of a Wi-Fi transmitter using their time- 
difference of arrival. Synchronicity requires the different ac¬ 
cess points to be synchronized in time. The authors achieve 


2 










this in their current implementation by connecting the ac¬ 
cess points to the same reference clock, and leave distributed 
time-synchronization for future work. We believe Chronos 
coupled with SourceSync (45) can complement Synchronic- 
ity by maintaining accurate time-synchronization between 
access points, while accounting for their relative time-of- 
flight. Finally recent theoretical work (54] |48) has proposed 
using a single large 8-antenna array to measure time-of-flight 
for indoor positioning. Unlike Chronos, these papers assume 
time and frequency synchronization of the access point and 
client, which is hard to ensure in practice (46). 

Our work is also related to other RF-based indoor lo¬ 
calization solutions. Such systems measure metrics other 
than time-of-flight, like angle-of-arrival and received signal 
power, across many RF receivers in the environment. Some 
achieve this using advanced infrastructure such as antenna 
arrays (30) [56] [53). Others rely on a combination of fin¬ 
gerprinting of the environment and modeling received sig¬ 
nal power at multiple client locations using multiple access 
points in the environment (47] [12] [8] |58) . Recent work re¬ 
quires neither (34] [20), but assumes the presence of multiple 
Wi-Fi access points in the environment. Unlike these sys¬ 
tems, Chronos infers location between a single pair of com¬ 
modity Wi-Fi devices, without requiring prior fingerprinting 
of the environment or support of the infrastructure. 

This paper is related to past systems on time- 
synchronization. For example, SourceSync (45) and 
FICA (15) measure time-of-arrival to synchronize the 
transmissions of distributed access points. However, these 
systems mainly focus on estimating time-of-arrival as 
opposed to time-of-flight, which is dominated by packet 
detection delay, as we show in ^5] In contrast, Chronos 
directly measures time-of-flight at a sub-nanosecond gran¬ 
ularity, bereft of packet detection delay, and can therefore 
complement these systems to further improve their accuracy. 

Finally, our work relates to past non-Wi-Fi localiza¬ 
tion systems, some measuring time-of-flight, e.g. ultra- 
wideband (32) , pulse radar [18), acoustic systems 1 5T] 37) , 
device-free localization systems (4] [44] [42), vision-based 
systems (33] a ED and inertial-measurement based sys¬ 
tems (36] pO ]. These systems either deploy custom infras¬ 
tructure |51[ |T8), assume special markers in the environ¬ 
ment (4l) , or suffer from poor accuracy |J50). In contrast, 
Chronos can leverage existing Wi-Fi radios that are ubiqui¬ 
tous in today’s mobile devices, laptops and access points. 


3. Overview of Chronos 

This section briefly outlines Chronos’s key challenges. 
Chronos’s core contribution is a new method that computes 
time of flight of a Wi-Fi signal. However, as mentioned in 
the introduction, obtaining highly accurate time-of-flight on 
Wi-Fi devices requires addressing three main challenges: 

• Limited Time Granularity: First, Chronos needs to 
compute accurate time-of-flight despite the limited clock 
resolution of commercial Wi-Fi cards (See Q. 
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Figure 2: Wi-Fi Bands: Depicts Wi-Fi bands at 2.4 GHz and 
5 GHz. Note that some of these frequencies (e.g. 5.5-5.7 GHz) are 
DFS bands in the U.S. that many 802.llh compatible 802.1 In ra¬ 
dios like Intel 5300 support. 


• Eliminating Packet Detection Delay: Second, it must 
disentangle time-of-flight from packet detection delay, 
which is often orders-of-magnitude larger (See §[5). 

• Combating Multipath: Third, Chronos should separate 
the time-of-flight of direct path of the wireless signal from 
that of all the remaining paths (See ^6). 

In the following sections, we describe how Chronos over¬ 
comes each of the above challenges as well as other practical 
issues to enable a robust system design. 


4. Measuring Time of Flight 

In this section, we describe how Chronos measures ac¬ 
curate time-of-flight of received signals, despite the limited 
time resolution of commodity Wi-Fi devices. For clarity, the 
rest of this section assumes signals propagate from the trans¬ 
mitter to a receiver along a single path with no detection de¬ 
lay. We address challenges stemming from packet detection 
delay and multipath in ^5] and ^respectively. 

Chronos’s approach is based on the following observation: 
Conceptually, if our receiver had a very wide bandwidth, it 
could readily measure time-of-flight at a fine-grained resolu¬ 
tion. Unfortunately, today’s Wi-Fi devices do not have such 
wide bandwidth. But there is another opportunity: Wi-Fi de¬ 
vices are known to span multiple frequency bands scattered 
around 2.4 GHz and 5 GHz. Combined, these bands span al¬ 
most one GHz of bandwidth. By making a transmitter and re¬ 
ceiver hop between these different frequency bands, we can 
gather many different measurements of the wireless channel. 
We can then “stitch together” these measurements to com¬ 
pute the time-of-flight, as if we had a very wideband radio. 

While channel hopping provides the intuition on how to 
compute accurate time-of-flight, transforming this idea into 
practice is not simple. Our method must account for the 
fact that many Wi-Fi bands are non-contiguous, unequally 
spaced, and even multiple GHz apart (see Fig. [2). 

Chronos’s solution to overcome these challenges exploits 
the phase of wireless channels. Specifically, we know from 
basic electromagnetics that as a signal propagates in time, 
it accumulates a corresponding phase depending on its fre¬ 
quency. The higher the frequency of the signal, the faster the 
phase accumulates. To illustrate, let us consider a transmit¬ 
ter sending a signal to its receiver. Then we can write the 
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wireless channel h as [52]: 

h = ae~ j27Tfr (1) 


Where a is the signal magnitude that captures its attenuation 
over the air, / is the frequency and r is the time-of-flight. The 
phase of this channel depends on time-of-flight as: 

Zh = —27r/r mod 2tt (2) 


Notice that the above equation depends directly on the sig¬ 
nal’s time-of-flight. In other words, it does not depend on the 
signal’s precise time-of-departure at the transmitter. Hence, 
we can use Eqn.[2]above to measure the time-of-flight r as: 


r 


Zh 

2tt/ 


moi f 


(3) 


The above equation gives us the time-of-flight modulo 
1 //. Hence, for a Wi-Fi frequency of 2.4 GHz, we can 
only obtain the time-of-flight modulo 0.4 nanoseconds. Said 
differently, transmitters with times-of-flight 0.1 ns, 0.5 ns, 
0.9 ns, 1.3 ns, etc. all produce identical phase in the wireless 
channel. In terms of physical distances, this means transmit¬ 
ters at distances separated by multiples of 12 cm (e.g., 3 cm, 
15 cm, 27 cm, 39 cm, etc.) all result in the same channel 
phase. Consequently, there is no way to distinguish between 
these transmitters using their phase on a single channel. 

Indeed, this is precisely why Chronos needs to hop be¬ 
tween multiple frequency bands {/i,... ,/„} and measure the 
corresponding wireless channels {/q,..., h n }. The result is 
a system of equations, one per frequency, that measure the 
time-of-flight modulo different values: 


Zhi 

2tt/i 

Zh 2 
2t r/ 2 


mod — 

h 

mod — 

n 


T 


^K 



(4) 


Notice that the above set of equations has the form of the 
well-known Chinese remainder theorem (24). Such equa¬ 
tions can be readily solved using standard modular arith¬ 
metic algorithms, even amidst noise 03:10 The theorem 
states that solutions to these equations are unique modulo a 
much larger quantity - the Least Common Multiple (LCM) 
of {l//i,...,l//J. For instance, Chronos can resolve time- 
of-flight uniquely modulo 200 ns using Wi-Fi frequency 
bands around 2.4 GHz. That is, it can resolve transmitters 
closer than 60 m in distance without ambiguity, which is suf¬ 
ficient for most indoor environments. 

To illustrate how the above system of equations works, 
consider a source at 0.6 m whose time-of-flight is 2 ns. Say 
the receiver measures the channel phases from this source on 


1 Algorithm [I] in ^provides a more general version of Chronos’s 
algorithm to do this while accounting for noise and multipath 


S 



T (ns) 

Figure 3: Measuring Time-of-Flight: Consider a wireless trans¬ 
mitter at a distance of 0.6 m, i.e. a time-of-flight of 2 ns. The phase 
of each Wi-Fi channel results in multiple solutions, depicted as col¬ 
ored lines, including 2 ns. However, the solution that satisfies most 
equations, i.e. has the most number of aligned colored lines is the 
true time-of-flight (2 ns). 

five candidate Wi-Fi channels as shown in Fig. [3] We note 
that a measurement on each of these channels produces a 
unique equation for r, like in Eqn.[4] Each equation has mul¬ 
tiple solutions, depicted as colored vertical lines in Fig. [3] 
However, only the correct solution of r will satisfy all equa¬ 
tions. Hence, by picking the solution satisfying the most 
number of equations (i.e., the r with most number of aligned 
lines in Fig. [3]), we can recover the true time-of-flight of 2 ns. 

Note that our solution based on the Chinese remainder 
theorem makes no assumptions on whether the set of fre¬ 
quencies {/i,... ,/„} are equally separated or otherwise. In 
fact, having unequally separated frequencies makes them 
less likely to share common factors, boosting the LCM. This 
means that counter-intuitively, the scattered and unequally- 
separated bands of Wi-Fi (see Fig. [2) are not a challenge, but 
an opportunity to resolve larger values of r. 

While the above provides a mathematical formulation of 
our algorithm, we describe below important systems consid¬ 
erations in applying Chronos to commercial Wi-Fi cards: 

• Chronos must ensure both the Wi-Fi transmitter and re¬ 
ceiver hop synchronously between multiple Wi-Fi chan¬ 
nels. Chronos achieves this using a channel hopping proto¬ 
col driven by the transmitter. Before switching frequency 
bands (every 2-3 ms in our implementation), the transmit¬ 
ter issues a control packet that advertises the frequency 
of the next band to hop to. The receiver responds with 
an acknowledgment and switches to the advertised chan¬ 
nel. Once the acknowledgment is received, the transmitter 
switches frequency bands as well. As a fail-safe, trans¬ 
mitters and receivers revert to a default frequency band 
if they do not receive packets or acknowledgments from 
each other for a given time-out duration on any band. 

• Our implementation of Chronos sweeps all Wi-Fi bands 
in 84 ms (12 times per second). This is within the chan¬ 
nel coherence time of indoor environments (46) and can 
empirically localize users at walking speeds (see §12.4| ). 
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• Chronos primarily targets device-to-device localization 
between two users where data is typically not exchanged. 
However, we discuss and evaluate the implications of 
Chronos’s protocol on data traffic in jff()]and §12. 3| 

• Finally, wireless transmitters and receivers experience car¬ 
rier frequency offsets (CFO). These offsets cause phase 
errors in measured wireless channels. CD describes how 
Chronos corrects frequency offsets, and additional phase 
offsets from differences in transmit and receive hardware. 

5. Eliminating Packet Detection Delay 

Our discussion so far has computed time-of-flight based 
on the wireless channels h t that signals experience when 
transmitted over the air on different frequencies The phase 
of such channels depends exclusively on the time-of-flight of 
the signal, and its frequency. In practice however, the mea¬ 
sured wireless channels at the receiver, hi, experience a delay 
in addition to time-of-flight: the delay in detecting the pres¬ 
ence of a packet. This delay occurs because Wi-Fi receivers 
detect the presence of a packet based on the energy of its first 
few time samples. The number of samples that the Wi-Fi re¬ 
ceiver needs to cross its energy detection threshold varies 
based on the power of the received signal, as well as noise. 
While this variation may seem small, packet detection delays 
are often an order-of-magnitude larger than time-of-flight, 
particularly in indoor environments, where time-of-flight is 
just a few tens of nanoseconds (See §12.1| ). 

Hence, our main goal here is to derive the true channel hi 
(which incorporates the time-of-flight alone) from the mea¬ 
sured channel hi (which incorporates both time-of-flight and 
packet detection delay). To do this, we exploit the fact that 
Wi-Fi uses OFDM. Specifically, the bits of Wi-Fi packets 
are transmitted in the frequency domain on several small fre¬ 
quency bins called OFDM subcarriers. This means that the 
wireless channels hi can be measured on each subcarrier. We 
then make the following main claim: The measured channel 
at subcarrier-0 does not experience packet detection delay, 
i.e. it is identical in phase to the true channel at subcarrier 0. 

To see why this claim holds, note that while time-of-flight 
and packet detection delay appear very similar, they occur 
at different stages of a signal’s lifetime. Specifically, time- 
of-flight occurs while the wireless signal is transmitted over 
the air (i.e., in passband). In contrast, packet detection delay 
stems from energy detection that occurs in digital process¬ 
ing once the carrier frequency has been removed (in base¬ 
band). Thus, time-of-flight and packet detection delay affect 
the wireless OFDM channels in slightly different ways. 

To understand this difference, consider a particular Wi-Fi 
frequency band i. Let h^ be the measured channel of OFDM 
subcarrier k, at frequency # experiences two phase ro¬ 
tations in different stages of the signal’s lifetime: 

• A phase rotation in the air proportional to the over-the-air 
frequency just like the true wireless channel h^. From 
Eqn.[2]in ^4j this phase value for a frequency fi# is: 

Ah U k = -27 xf uk T, 


where r is the time-of-flight. 

• An additional phase rotation due to packet detection after 
the removal of the carrier frequency. This additional phase 
rotation can be expressed in a similar form as: 

A uk = -2n(fi' k 

where is the packet detection delay. 

Thus, the total measured channel phase at subcarrier k is: 

Z.h uk =^h uk + A uk (5) 

=-2rf kk T - 2n(f uk -fi,o)Si (6) 

Notice from the above equation that the second term = 
—27 x(fi^ — fi,o)5i = 0 at precisely k = 0. In other words, at 
the zero-subcarrier of OFDM, the measured channel h^ is 
identical in phase to the true channel h^ over-the-air which 
validates our claim. 

In practice, this means that we can apply the Chinese Re¬ 
mainder theorem as described in Eqn. [4] of ^4] at the zero- 
subcarriers (i.e. center frequencies) of each Wi-Fi frequency 
band. In the U.S., Wi-Fi at 2.4 GHz and 5 GHz has a to¬ 
tal of 35 Wi-Fi bands with independent center frequencies]^] 
Therefore, a sweep of all Wi-Fi frequency bands results in 
35 independent equations like in Eqn. [4] which we can solve 
to recover time-of-flight. 

However, one problem still needs to be addressed. So far 
we have used the measured channel at the zero-subcarrier 
of Wi-Fi bands. However, Wi-Fi transmitters do not send 
data on the zero-subcarrier, meaning that this channel sim¬ 
ply cannot be measured. This is because the zero-subcarrier 
overlaps with DC offsets in hardware that are extremely dif¬ 
ficult to remove dun). So how can one measure channels 
on zero-subcarriers if they do not even contain data? 

Fortunately, Chronos can tackle this challenge by using 
the remaining Wi-Fi OFDM subcarriers, where signals are 
transmitted. Specifically, it leverages the fact that indoor 
wireless channels are based on physical phenomena. Hence, 
they are continuous over a small number of OFDM subcar¬ 
riers p9| . This means that Chronos can interpolate the mea¬ 
sured channel phase across all subcarriers to estimate the 
missing phase at the zero-subcarrier]^] Indeed, the 802.1 In 
standard [2] measures wireless channels on as many as 30 
subcarriers in each Wi-Fi band. Hence, interpolating be¬ 
tween the channels not only helps Chronos retrieve the mea¬ 
sured channel on the zero-subcarrier, but also provides addi¬ 
tional resilience to noise. 

To summarize, Chronos applies the following steps to ac¬ 
count for packet detection delay: (1) It obtains the measured 
wireless channels on the 30 subcarriers on the 35 available 
Wi-Fi bands; (2) It interpolates between these subcarriers to 
obtain the measured channel phase on the zero-subcarriers 
on each of these bands, which is unaffected by packet detec- 

2 Including the DFS bands at 5 GHz in the U.S. which are supported 
by many 802.1 lh-compatible 802.1 In radios like the Intel 5300. 

3 Our implementation of Chronos uses cubic spline interpolation. 
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(a) Testbed (b) Multipath Profile 


Figure 4: Combating Multipath: Consider a signal propagating 
from a transmitter to a receiver along three paths as shown in (a): 
an attenuated direct path and two reflected paths of lengths 5.2 ns, 
10 ns and 16 ns respectively. These paths can be separated by using 
the inverse discrete Fourier transform as shown in (b). The plot has 
three peaks corresponding to the propagation delays of the three 
paths, with peak magnitudes scaled by their relative attenuations. 

tion delay. (3) It retrieves the time-of-flight using the result¬ 
ing 35 channels. 

6. Combating Multipath 

So far, our discussion has assumed that a wireless signal 
propagates along a single direct path between its transmitter 
and receiver. However, indoor environments are rich in mul¬ 
tipath, causing wireless signals to bounce off objects in the 
environment like walls and furniture. Fig. |4ja) illustrates an 
example where the signal travels along three paths from its 
sender to receiver. The signals on each of these paths prop¬ 
agate over the air incurring different time delays as well as 
different attenuations. The ultimate received signal is there¬ 
fore the sum of these multiple signal copies, each having ex¬ 
perienced a different propagation delay. Fig. |4jb) represents 
this using a multipath profile. This profile has peaks at the 
propagation delays of signal paths, scaled by their respec¬ 
tive attenuations. Hence, Chronos needs a mechanism to find 
such a multipath profile, so as to separate the propagation de¬ 
lays of different signal paths. This allows it to then identify 
the time-of-flight as the least of these propagation delays, i.e. 
the delay of the most direct (shortest) path. 

6.1 Computing Multipath Profiles 

Let us assume that wireless signals from a transmitter 
reach a receiver along p different paths. The received sig¬ 
nal from each path corresponds to amplitudes {a \,... ,a p } 
and propagation delays {r\,..., r p }. Observe that our ear¬ 
lier Eqn. [T] considers only a single path experiencing prop¬ 
agation delay and attenuation. In the presence of multipath, 
we can extend this equation to write the measured channel 

o on center-frequency /•,o as the sum of the channels on 
each of these paths, i.e.: 

p 

hi,o = ake~ j27r ^° Tk , for i m 1,..., n (7) 

k= 1 


At this point, we need to disentangle these different paths 
and recover their propagation delays. To do this, notice that 
the above equation has a familiar form - it is the well-known 
Discrete Fourier Transform. Thus, if one could obtain the 
channel measurements at many uniformly-spaced frequen¬ 
cies, a simple inverse-Fourier transform would separate indi¬ 
vidual paths. Such an inverse Fourier transform has a closed- 
form expression that can be used to obtain the propagation 
delay of all paths and compute the multipath profile (up to a 
resolution defined by the bandwidth). 

Wi-Fi frequency bands, however, are not equally spaced 
- they are scattered around 2.4 GHz and multiple non¬ 
contiguous chunks at 5 GHz, as shown in Fig. [2] While we 
can measure hi ,o at each Wi-Fi band, these measurements 
will not be at equally spaced frequencies and hence cannot 
be simply used to compute the inverse Fourier transform. In 
fact, since our measurements of the channels are not uni¬ 
formly spaced, we are dealing with the Non-uniform Discrete 
Fourier Transform or NDFT 0 - To recover the multipath 
profile, we need to invert the NDFT. 


6.2 Inverting the NDFT 

To find the multipath profile, we must invert a Non Uni¬ 
form Discrete Fourier Transform (NDFT). Computing the 
inverse of the NDFT is a known problem that has been stud¬ 
ied extensively in different contexts (2l||T4|. Specifically, the 
NDFT is an under-determined system, where the responses 
of multiple frequency elements are unavailable. Therefore, 
the inverse of such a Fourier transform no longer has a sin¬ 
gle closed-form solution, but several possible solutions. So 
how can Chronos pick the best among those solutions to find 
the true times-of-flight of the signal? 

Chronos solves for the inverse-NDFT by adding a con¬ 
straint to the inverse-NDFT optimization. Specifically, this 
constraint favors solutions that are sparse, i.e., have few 
dominant paths. Intuitively, this stems from the fact that 
while signals in indoor environments traverse several paths, 
a few paths tend to dominate as they suffer minimal atten¬ 
uation |9|]|^] Indeed other localization systems make this as¬ 
sumption as well, albeit less explicitly. For instance, antenna- 
array systems can resolve a limited number of dominant 
paths based on the number of antennas they use. 

We can formulate the sparsity constraint mathematically 
as follows. Let the vector p sample inverse-NDFT at m 
discrete values r G {r\, ... ,r m }. Then, we can introduce 
sparsity as a simple constraint in the NDFT inversion prob¬ 
lem that minimizes the L-l norm of p. Indeed, it has been 
well-studied in optimization theory that minimizing the L-l 
norm of a vector favors sparse solutions for that vector 0 - 
Thus, we can write the optimization problem to solve for the 


4 We empirically evaluate the sparsity of indoor multip ath pro files 
in typical line-of-sight and non-line-of-sight settings in j |12.1| 
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inverse-NDFT as: 


min 11P11 i (8) 

s.t. Wh-FpWl = 0 (9) 

where, T is the n x m Fourier matrix, i.e. = e~^ 27T ^° Tk , 
h = h n fi] T is the n x 1 vector of wireless channels 

at the n different center-frequencies {/i ?0 , •.. ,f n , o}, || • ||i is 
the L-l norm, and || • ||2 is the L-2 norm. Here, the constraint 
makes sure that the Discrete Fourier Transform of p is h, as 
desired. In other words, it ensures p is a candidate inverse- 
NDFT solution of h. The objective function favors sparse 
solutions by minimizing the L-l norm of p. 

We can re-formulate the above optimization problem us¬ 
ing the method of Lagrange multipliers as: 

min||h-7'p||2+Q:||p||i (10) 

P 

Notice that the factor a is a sparsity parameter that enforces 
the level of sparsity. A bigger choice of a leads to fewer non¬ 
zero values in p. 

The above objective function is convex but not differen¬ 
tiable. Our approach to optimize for it borrows from prox¬ 
imal gradient methods, a special class of optimization al¬ 
gorithms that have provable convergence guarantees (26) . 
Specifically, our algorithm takes as inputs the measured 
wireless channels h at the frequencies {/i ? o, •.. ,/«, 0 } and the 
sparsity parameter a. It then applies a gradient-descent style 
algorithm by computing the gradient of differentiable terms 
in the objective function (i.e. the L-2 norm), picking sparse 
solutions along the way (i.e. enforcing the L-l norm). Algo¬ 
rithm [I] summarizes these steps. Chronos runs this algorithm 
to invert the NDFT and find the multipath profile. 


1 Algorithm to Compute Inverse NDFT 

> Given: Measured Channels, h 

> T\ Non-uniform DFT matrix, such that Ti& — e~ j2nfifiTk 

> a: Sparsity parameter; e: Convergence Parameter 

> Output: Inverse-NDFT, p 

> Initialize po to a random value, t — 0, 7 = \\p \\ 2 ■ 
while converged — false do 

Pr+l =SPARSIFY(p, - 7J r *(Ep t ~ h), 70) 
if llPf+i -Pf ||2 < e then 
converged — true 
P = Pr+i 

else 

t — t T 1 

end if 
end while 

function SPARSiFY(p,f) 

for i = 1,2, ...length( p) do 

if | p { ‘| < t then 

Pi = 0 

else 

n — n .Mul 
p- - p- | Pi | 

end if 

end for 
end function 


Finally, Chronos needs to resolve the time-of-flight of the 


wireless device based on its multipath profile. To do this, 
Chronos leverages a simple observation: Of all the different 
paths of the wireless signal, the direct path is the shortest. 
Hence, the time-of-flight of the direct path is the propagation 
delay corresponding to the first peak in the multipath profile. 

We make the following observations: (1) By making 
the sparsity assumption, we lose the propagation delays of 
extremely weak paths in the multipath profile. However, 
Chronos only needs the propagation delay of the direct path. 
As long as this path is among the dominant signal paths, 
Chronos can retrieve it accurately. Of course, in some un¬ 
likely scenarios, the direct path may be too attenuated in 
the multipath profile. Like most localization systems, includ¬ 
ing angle-of-arrival based approaches, this results in outliers 
with poorer localization accuracy. (2) Leveraging sparse re¬ 
covery of time-of-flight is key to Chronos’s high resolution. 
Specifically, sparse recovery algorithms are well-known to 
recover sparse useful information at high resolution, as op¬ 
posed to all information at low resolution ED- Our results 
in |12.1| depict the sparsity of representative multipath pro¬ 
files in line-of-sight and non-line-of-sight, and show its im¬ 
pact on overall accuracy in time-of-flight. 

7. Correcting for Frequency Offsets 

As mentioned in §[4| Wi-Fi radios in practice experience 
Carrier Frequency Offsets (CFO) that need to be corrected, 
to apply Chronos’s algorithms. These offsets occur due to 
small differences in the carrier frequency of the transmitting 
and receiving radio. Such differences accumulate quickly 
over time and result in large phase errors in wireless chan¬ 
nel measurements, that must be corrected to retrieve time- 
of-flight. We refer to these measured channels from Wi-Fi 
radios as channel state information (CSI). 

To remove frequency offsets from CSI at the receiver, 
Chronos exploits the ACKs that receivers send for every 
packet from the transmitter during Chronos’s channel hop¬ 
ping protocol. This means that Chronos can access another 
CSI - this time measured at the transmitter for the receiver’s 
ACK. This additional CSI is valuable to help mitigate the 
frequency offset. To see why, let ff x 0 anddenote the center- 
frequencies of the i th frequency band of Wi-Fi at the fre¬ 
quency offset. The frequency offset measured at the receiver 
for the transmitter’s packet is therefore/^ — ffo- As a re¬ 
sult, any phase error in the CSI is proportional to this offset. 
In contrast, the frequency offset measured at the transmit¬ 
ter for the receiver’s ACK is ff x 0 — ff { g, since the transmitter 
and receiver flip roles. In other words, its frequency offset 
is negative of that of the receiver. As a result, its measured 
phase error is also the negative of the phase error at the re¬ 
ceiver. This means that by adding the phases at the receiver 
and transmitter (or equivalently, multiplying the CSIs), we 
can eliminate any phase error due to frequency offset. 

Mathematically, we can observe this property by writ¬ 
ing the channel state information CSI ™ Q (t) and CSI ^ Q (t) cor¬ 
rupted by frequency offsets, measured at the receiver and 
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transmitter respectively, at center-frequencies/^,//^ of Wi¬ 
Fi frequency band i at time t , as follows: 

CSI&(f) = A,y(/5->S>' (11) 

CSl“ 0 (r) = hiflt (12) 

Notice that without frequency offsets, the transmitter’s chan¬ 
nel equals the receiver’s, barring a constant factor k that can 
be pre-calibrated. Here, k, depends only on the transmit and 
receive chains of the device, and is independent of device lo¬ 
cation. This is a well-known property of wireless channels 
called reciprocity (22) . We can therefore multiply the above 
equations to recover the wireless channel as follows: 

hi 3 = -CSI™ 0 (r)CSI» (13) 

Kj 

Of course, the above formulation helps us only retrieve the 
square of the wireless channels hf 0 . However, this is not an 
issue: Chronos can directly feed hf 0 into its algorithm (Alg. 1 
in ^ instead of h L {). Then the first peak of the resulting mul¬ 
tipath profile will simply be at twice the time-of-flight. 

To see why, let us look at a simple example. Consider 
a transmitter and receiver obtaining their signals along two 
paths, with propagation delays 2 ns and 4 ns. We can write 
the square of the resulting wireless channels from Eqn.[7]for 
frequency band i in a simple form: 

h 2 0 = (a x e~ j2 ^ 0X2 + a 2 e~ j2 ^ ° x4 ) 2 

= a j e -J^f,, 0 x 2 x 2 + 2 ai a 2 e~ i2nfi -° x(2+4) + aje~ J27rf - oX4x2 

= bxe- j27vfi - oX4 + b 2 e~ j2nf 0X6 + b 3 e~ j2nfi - 0X8 

Where b\ = a\, b 2 = 2a x a 2 , b 2 = a\. Clearly, the above 
equation has a form similar to a wireless channel with prop¬ 
agation delays 4 ns, 6 ns and 8 ns respectively. This means 
that applying Chronos’s algorithm will result in peaks pre¬ 
cisely at 4 ns, 6 ns and 8 ns. Notice that in addition to 4 ns 
and 8 ns that are simply twice the propagation delays of gen¬ 
uine paths, there is an extra peak at 6 ns. This peak stems 
from the square operation in h? 0 and is a sum of two delays. 
However, the sum of any two delays will always be higher 
than twice the lowest delay. Consequently, the smallest of 
these propagation delays is still at 4 ns — i.e., at twice the 
time-of-flight. A similar argument holds for larger number 
of signal paths, and can be used to recover time-of-flight. 

We make a few important observations: (1) In practice, 
the forward and reverse channels cannot be measured at ex¬ 
actly the same t but within short time separations (tens of mi¬ 
croseconds), resulting in a small phase error. However, this 
error is significantly smaller than the error from not compen¬ 
sating for frequency offsets altogether (for tens of millisec¬ 
onds). The error can be resolved by averaging over several 
packets. (2) Constants such as k and other delays in trans¬ 
mit/receive hardware result in a constant error in time-of- 
flight. These can be pre-calibrated a priori and only once by 
measuring time-of-flight to a device at a known distance. 

8. Computing Distances and Location 



Figure 5: Chronos Personal Drone: We implement Chronos on 
an AscTec Hummingbird quadrotor with an AscTec Atomboard. 


So far, we have explained how Chronos measures the 
time-of-flight between two antennas on a pair of Wi-Fi cards. 
One can then compute the distance between the two anten¬ 
nas (i.e., the two devices) by multiplying the time-of-flight 
by the speed of light. One can also compute the location by 
intersecting multiple such distances. 

For example, consider a two-antenna receiver that aims to 
compute its location relative to a single-antenna transmitter. 
The receiver first applies Chronos’s algorithm to measure the 
time-of-flight of the transmitter’s signal to its two receive an¬ 
tennas. When multiplied by the speed of light this provides 
two distances of the two receive antennas from the transmit¬ 
ter. Hence, the transmitter must lie at the intersection of the 
two circles, centered around each receive antenna with radii 
defined by these distances. 

In general, two distances are not enough to compute the 
location as two circles typically intersect at two points. 
Chronos can resolve the ambiguity using one of two strate¬ 
gies: (1) If the receiver has a third antenna, Chronos can use 
it to find a third circle on which the transmitter should lie. 
The three circles will together intersect at a unique point (as¬ 
suming the antennas are not co-linear). Notice that if the 
three circles do not intersect exactly (e.g., due to noise), 
Chronos can use well-known least-squares optimizations to 
pick the point closest to the three circles (34j. Similarly, if 
the transmitter has more than one antenna, Chronos can im¬ 
prove the localization accuracy by computing pairwise dis¬ 
tances between the transmit and receive antennas and then, 
incorporating them in the optimization problem. (2) A sec¬ 
ond approach to remove location ambiguity leverages mo¬ 
bility. A receiver can move towards what it believes to be 
the transmitter’s location, and re-run Chronos’s algorithm. If 
the transmitter indeed moved closer, the chosen location is 
correct. If not, one must pick the other possible location of 
the transmitter. We employ this strategy to disambiguate the 
transmitter’s location for the personal drone in ^9] 

9. Application to Personal Drones 

To illustrate Chronos’s capabilities, we apply it to indoor 
personal drones (43} . These drones can follow users around 
while maintaining a convenient distance relative to the mo- 
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bile device in the user’s pocket. Knowing the distance to the 
user allows the drone to take clear optimal pictures by ensur¬ 
ing that the user is within the frame of view at the right level 
of zoom. Users can leverage these drones to take pictures or 
videos of them while they are performing an activity, even in 
indoor settings where GPS is unavailable. 

This application highlights Chronos’s unique benefits: 


• Device-to-device solution: A key feature of Chronos is its 
ability to deliver device-to-device localization - i.e., en¬ 
abling devices with commercial Wi-Fi cards to accurately 
localize each other without support from surrounding in¬ 
frastructure. Thus, Chronos requires only a Wi-Fi enabled 
drone and a Wi-Fi device on the user. The user may use his 
personal drone to record his activities anywhere, whether 
at home, at work or in the gym, without requiring the ac¬ 
cess points in these buildings to support localization. 

• Uses commercial Wi-Fi cards: Indoor drones can carry 
only limited payload for stable flight over long durations. 
In other words, drones simply cannot carry state-of-the- 
art accurate localization hardware such as antenna arrays. 
Fortunately, since Chronos is compatible with commodity 
Wi-Fi cards, it is possible integrate it with a light-weight 
computing module that weighs 90 grams and can be car¬ 
ried by small indoor drones. 


We built Chronos over an AscTec Hummingbird quadro- 
tor equipped with a Go-pro camera, as shown in Fig. 0To 
localize the quadrotor, Chronos uses a 3-antenna Wi-Fi ra¬ 
dio and intersects the distances of the user’s device to its 
3-antennas. The distance measurements are integrated with 
drone navigation using a standard negative feedback-loop 
robotic controller GD- Specifically, this controller measures 
the current distance of the user’s mobile device. If the user 
is closer than expected, the drone takes a discrete step fur¬ 
ther away and vice-versa. Such controllers are well-known 
to converge efficiently to stable solutions GD- Our results 
in §12.4 show that Chronos converges to optimal locations 
that maintain stable distances. Further, our approach also 
benefits from an inherent synergy between Chronos’s lo¬ 
calization and the robotic controller. Specifically, the feed¬ 
back controller invokes Chronos’s algorithm multiple times 
to compute its precise distance to the user. In doing so, it can 
average across these invocations and reject outliers to main¬ 
tain this distance at a much higher accuracy than Chronos’s 
native algorithm, as we show in §12.4 


10. Limitations and Trade-Offs 

In this section, we discuss the limitations and trade-offs in 
Chronos’s design. 

Frequency Band Hopping: Chronos requires wireless de¬ 
vices to hop between Wi-Fi frequency bands. Our implemen¬ 
tation hops between all bands of Wi-Fi in 84 ms (see §12.3| ). 
A natural question to ask is how this hopping affects data 
traffic and user experience. Note that Chronos is primarily 
targeted for localization between a pair of Wi-Fi user devices 


20 m 





hO 

CD 


Figure 6: Testbed: Blue dots show candidate device locations. 


that may otherwise not exchange data. However, some users 
may be interested in running Chronos on a single access 
point in home environments, where there may not be mul¬ 
tiple access points covering the same physical space. Such 
access points cannot transmit/receive data to other clients 
as they localize. §12. 3| shows that occasional demands for 
localization every tens of seconds minimally impacts TCP 
and video applications on these clients. But more frequent 
requests for localization may necessitate deploying a dedi¬ 
cated Chronos access point exclusively for in-home localiza¬ 
tion. Finally, since Chronos sends few packets per frequency 
band, it does not significantly impact nearby Wi-Fi networks. 
Antenna Separation: Chronos’s accuracy in localizing a 
device improves with greater separation between its receive 
antennas. As the separation between a pair of antennas be¬ 
comes larger, the resulting localization circles experience 
smaller overlap. This means that their point of intersection is 
less sensitive to noise, improving localization accuracy. Con¬ 
sequently, Chronos’s positioning accuracy on a Wi-Fi access 
point which can afford larger separation between antennas 
is higher than Chronos between a pair of user devices (e.g. 
laptops or tablets). Our results in §1 2.2 1 empirically evaluate 
this trade-off in typical indoor environments. 


11. Implementation 

We implemented Chronos as a software patch to the iwl- 
wifi driver on Ubuntu Linux running the 3.5.7 kernel. To 
measure channel-state-information, we leverage the 802.11 
CSI Tool [23] for the Intel 5300 Wi-Fi card. We measure 
wireless channels on both 2.4 GHz and 5 GHz Wi-Fi bands 0 

Unless specified otherwise, we pair two Chronos devices 
by placing each device in monitor mode with packet injec¬ 
tion support on the same Wi-Fi frequency. We implemented 
Chronos’s channel hopping protocol (see © in the iwl- 
wifi driver using high resolution timers (hrtimers), which 
can schedule kernel tasks such as packet transmits at mi- 

5 The Intel 5300 Wi-Fi card is known to have a firmware issue on the 
2.4 GHz bands that causes it to report the phase of the channel Z/z;,o 
modulo 7t/2 (instead of the phase modulo 2i r) (20) . We resolve this 
issue by performing Chronos’s algorithm at 2.4 GHz on h A iQ instead 
of hi$. This does not affect the fact that the direct path of the signal 
will continue being the first peak in the inverse NDFT (like in CD- 
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Figure 7: Accuracy in Time of Flight: (a) measures the CDF of error in time-of-fhght between two devices in Line of Sight (LOS) and 
Non-Line of Sight (NLOS). (b) plots representative multipath profiles, (c) plots histograms of time-of-fhght and packet detection delay. 


crosecond granularity. Since the 802.11 CSI Tool does not 
report channel state information for Link-Layer ACKs re¬ 
ceived by the card, we use packet-injection to create and 
transmit special acknowledgments directly from the iwlwifi 
driver to minimize delay between packets and acknowledg¬ 
ments. These acknowledgments are also used to signal the 
next channel that the devices should hop to, as described 
in Finally we process the channel state information to 
infer time-of-flight and device locations purely in software 
written in part in C++, MEX and MATLAB. 

12. Results 

We evaluate Chronos using the testbed in Fig. [6] 

12.1 Accuracy in Time-of-Flight 

In this experiment, we evaluate whether Chronos can de¬ 
liver on its promise of measuring sub-nanosecond time-of- 
flight between a single pair of commodity Wi-Fi devices. 

Method: We conduct our main experiments in a floor of a 
large office building measuring 20 m x 20 m as shown in 
Fig. [6] The floor has multiple offices, a lounge area, con¬ 
ference rooms, metal cabinets, computers and furniture. We 
perform our experiments using two Thinkpad W300 Lap¬ 
tops equipped with 3-antenna Intel 5300 Wi-Fi cards. We 
placed the two devices randomly at any of 30 randomly cho¬ 
sen locations, as shown by the blue circles in the figure, with 
their pairwise distance up to 15 m. We perform experiments 
for pairs of locations both in line-of-sight and non-line-of- 
sight. We measure the ground-truth of these locations using 
a combination of architectural drawings of our buildings and 
a Bosch GLM50 laser distance measurement tool (T), which 
measures distances up to 50 m with an accuracy of 1.5 mm. 
We repeat the experiment multiple times and measure the 
time-of-flight in each instance. We also compute the packet- 
detection delay of each packet using channel phase (see © 
to gauge its effect on the measurement of time-of-flight. 

Time-of-Flight Results: We first evaluate Chronos’s ac¬ 
curacy in time-of-flight. Fig. |7(a)| depicts the CDF of the 
time-of-flight of the signal in line-of-sight settings and non- 
line-of-sight. We observe that the median errors in time- 
of-flight estimation are 0.47 ns and 0.69 ns respectively 
(95 th percentile: 1.96 ns and 4.01 ns). Our results show that 


Chronos achieves its promise of computing time-of-flight at 
sub-nanosecond accuracy. To put this in perspective, con¬ 
sider SourceSync (45), a state-of-the-art system for time syn¬ 
chronization. SourceSync achieves 95 th percentile synchro¬ 
nization error up to 20 ns, using advanced software radios. 
In contrast, Chronos achieves order-of-magnitude lower er¬ 
ror in time-of-flight using commodity Wi-Fi cards. However, 
we point out that unlike indoor positioning, tens of nanosec¬ 
onds of error is sufficient for time-synchronization, which is 
the application SourceSync targets. 

Multipath Profile Results: Next, we plot candidate multi- 
path profiles computed by Chronos. Fig. |7(b)| plots represen¬ 
tative multipath profiles in line-of-sight and multipath envi¬ 
ronments. We note that both profiles are sparse, with the pro¬ 
file in multipath environments having five dominant peaks. 
Across experiments, the mean number of dominant peaks in 
the multipath profiles is 5.05 on average, with standard devi¬ 
ation 1.95 — indicating that they are indeed sparse. As ex¬ 
pected, the profile in line-of-sight has even fewer dominant 
peaks than the profile in multipath settings. In both cases, 
we observe that the leftmost peaks in both the profiles corre¬ 
spond to the true location of the source. Further, we observe 
that the peaks in both profiles are sharp due to two reasons: 
1) Chronos effectively spans a large bandwidth that includes 
all Wi-Fi frequency bands, leading to high time resolution; 2) 
Chronos’s resolution is further improved by exploiting spar¬ 
sity that focuses on retrieving the sparse dominant peaks at 
much higher resolution, as opposed to all peaks. 

Packet Detection Delay Results: We compare time-of- 
flight in indoor environments against packet detection de¬ 
lay. Fig. |7(c)| depicts histograms of both packet detection de¬ 
lay and time-of-flight across experiments. Chronos observes 
a median packet detection delay of 177 ns across experi¬ 
ments. We emphasize two key observations: (1) Packet de¬ 
tection delay is nearly 8x larger than the time-of-flight in 
our typical indoor testbed. (2) It varies dramatically between 
packets, with a high standard deviation of 24.76 ns. In other 
words, packet detection delay is a large contributor to time- 
of-arrival that is highly variable, and therefore, hard to pre¬ 
dict. This means that if left uncompensated, these delays 
could lead to a large error in time-of-flight measurements. 
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(a) Accuracy with distance 


(b) Localization Error (Small separation) (c) Localization Error (Large separation) 


Figure 8: (a) Accuracy with Distance: Plots the error in distance/time across the ground-truth distance between transmitter and receiver, 
(b, c) Localization Accuracy: Plots CDF of localization error using (b) a client with mean antenna separation of 30 cm and (c) an access 
point with antenna separation of 100 cm for transmitter and receiver in Line-of-Sight (LOS) and Non-Line-of-Sight (NLOS). 


Our results therefore reinforce the importance of accounting 
for these delays and demonstrate Chronos’s ability to do so. 

Distance Results: Fig. |8(a)| plots the median and standard 
deviation of error in distance computed between the trans¬ 
mitter and receiver against their true relative distance. We 
observe that this error is initially around 10 cm and increases 
to at most 25.6 cm at 12-15 meters. The increase is primarily 
due to reduced signal-to-noise ratio at further distances. 


12.2 Localization Accuracy 


Next, we evaluate Chronos’s accuracy in finding the in¬ 
door position of one device relative to another. 

Method: We repeat the experiment for the setup in §12.1 
using a pair of 3-antenna client laptops with antennas sep¬ 
arated by a mean distance of 30 cm. We consider pairs of 
locations where the distance between the devices vary up to 
15 m. We then measure the time-of-flight of the transmit¬ 
ter’s signal to each antenna of the receiver. We multiply this 
quantity by the speed of light to measure the pairwise dis¬ 
tances between the antennas on the transmitter and the re¬ 
ceiver. We perform outlier rejection on this set of distance 
estimates to discard estimates that do not fit the geometry of 
the relative antenna placements on these devices. Next, we 
use the remaining distance estimates to compute the location 
of the device using a least-square optimization formulation 
(as stated in §[8}. We repeat the experiment multiple times in 
line-of-sight and non-line-of-sight. 


Results: Fig. |8(b) plots a CDF of localization error using 
Chronos in different settings. The device’s median position¬ 
ing error for line of sight scenarios is 58 cm and 118 cm in 
line-of-sight and non-line-of-sight. Thus, Chronos achieves 
state-of-the-art indoor localization accuracy between a pair 
of user devices without third party support. 

As mentioned in jj fT0| Chronos’s accuracy depends on the 
separation between antennas. In particular, users may wish to 
run Chronos to localize their device relative to the single Wi¬ 
Fi access point in their home, where multiple access points 
covering the same area may be unavailable. Such an access 
point can afford greater separation between antennas than 
a user device. To evaluate this, we repeated the above ex¬ 


periment with the receiving laptop emulating a Wi-Fi access 
point with antennas separated by 100 cm. In this setting, the 
median localization error, reduces as expected to 35 cm and 
62 cm in line-of-sight and non-line-of-sight (see Fig. |8(c) ). 


12.3 Impact on Network traffic 


Chronos is primarily targeted to enable localization- 
between a pair of user devices, which may not otherwise 
communicate data between each other directly. However, an 
interesting question is the impact of Chronos on network 
traffic, if one of the devices is indeed serving traffic, e.g., 
a Wi-Fi access point. This experiment answers three ques¬ 
tions in this regard: (1) How long does Chronos take to hop 
between all Wi-Fi bands? (2) How does Chronos impact real¬ 
time traffic like video streaming applications? (3) How does 
Chronos affect TCP? We address these questions below: 


Method: We consider three Thinkpad W530 Laptops, one 
emulating an access point (using hostapd) and two clients. 
We assume client-2 requests the access point for indoor lo¬ 
calization at t = 6 s. We measure the time Chronos incurs to 
hop between the 35 Wi-Fi bands. Meanwhile, client-1 runs a 
long-lasting traffic flow. We consider two types of flows: (1) 
VLC video stream over RTP; (2) TCP flow using iperf. We 
repeat the experiment 30 times and find aggregate results. 


Results: Fig. |9 (a) | depicts the CDF of the time that Chronos 
incurs to hop over all Wi-Fi bands. We observe that the me¬ 
dian hopping time is 84 ms for the Intel 5300 Wi-Fi card, in 
tune with past work on other commercial Wi-Fi radios m- 
Next, Fig. 9(b) plots a representative trace of the cumula¬ 
tive bytes of video received over time of a VLC video stream 
run by client-1 (solid blue line). The red line plots the cumu¬ 
lative number of bytes of video played by the client. Notice 
that at t = 6 s, there is a brief time span when no new bytes 
are downloaded by the client (owing to the localization re¬ 
quest). However, in this interval, the buffer has enough bytes 
of video to play, ensuring that the user does not perceive a 
video stall (i.e. the blue and red lines do not cross). In other 
words, buffers in today’s video streaming applications can 
largely cushion such short-lived outages (28] [27), m inimiz- 
ing impact on user experience. Similarly, Fig. |9(c)| depicts 
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(a) Hopping Time (b) Video Streaming (c) TCP Throughput 

Figure 9: Impact on Network Traffic: (a) measures the CDF time taken by Chronos to hop between all Wi-Fi bands - a small value of 
84 ms. Consider a client-1 with a long-running traffic flow to an access point. The access point is asked to localize another client-2 at t = 6 s. 
(b) depicts a representative trace of the number of bytes of data downloaded and data played over time if the client-1 views a VLC video 
stream, (c) measures the throughput if client-1 runs a TCP flow using iperf. In either case, the impact of client-l’s flow is minimal at t — 6 s. 



(a) Error in Distance (b) Drone Trajectory (c) Picture of User 

Figure 10: Application to Personal Drones: The personal drone uses Chronos to maintain a constant distance of 1.4 m to the user, (a) 
depicts the CDF of error in distance of the drone relative to 1.4 m. (b) depicts a candidate trajectory of the drone, (c) shows an example picture 
of the user (face blurred for anonymity) taken by the drone. Since its Go-Pro uses a wide-angle lens, the user is fully in-frame at 1.4 m. 


a representative trace of the throughput over time of a TCP 
flow at client-1. We observe that the TCP throughput dips 
only slightly by 6.5% at t = 6 s, when client-2 requests lo¬ 
cation. However, we emphasize that if more frequent local¬ 
ization is desired, we recommend deploying an access point 
or Wi-Fi beacon exclusively for indoor positioning. 

12.4 Application to Personal Drones 

To illustrate Chronos’s capabilities, we evaluate how 
Chronos effectively guides a personal drone to follow a 
user’s device at an optimal distance to take pictures. 

Method: Our personal drone is an AscTec Humming¬ 
bird quadrotor equipped with the AscTec Atomboarcj^] light¬ 
weight computing platform (with the Intel 5300 Wi-Fi card), 
a Go-pro camera and a Yei-Technology motion sensor. We 
3-D print an enclosure to mount all these components safely 
atop the quadrotor. Fig. [5] depicts our setup. Note that the In¬ 
tel 5300 Wi-Fi card supports 3-antennas; the fourth antenna 
on the quadrotor is placed only for balance and stability. 

We perform our personal drone experiments in a 6 m x 5 m 
room augmented with the VICON motion capture system 
[ 3 j. The motion capture room uses an array of twelve in¬ 
frared cameras to track devices tagged with infrared markers 

6 While we use the atomboard due to its light-weight of only 90 
grams, we note that Chronos is compatible with other small com¬ 
puting modules like the Intel Galileo or Fit-PC. 


at sub-centimeter accuracy. We use the motion tracking sys¬ 
tem to find the ground-truth trajectories of the personal drone 
and user device. In each experiment, the personal drone 
tracks an ASUS EEPC netbook with the Intel 5300 Wi-Fi 
card held by a user. The user walks along a randomly chosen 
trajectory. The drone maintains a constant height and follows 
the user using Chronos’s negative-feedback loop algorithm, 
described in §(9]to maintain a constant distance of 1.4 m rela¬ 
tive to the user’s device. The drone also captures photographs 
of the user along the way using the Go-Pro camera mounted 
on the Hummingbird quadrotor, keeping the user at 1.4 m in 
focus. The drone uses the compass on the user’s device and 
the quadrotor to ensure that its camera always faces the user. 


Results: Fig. 1 10(a) measures the CDF of root mean squared 
deviation in distance of the drone relative to the desired value 
of 1.4 m — a median of 4.17 cm. Our results reveal that 
the drone tightly maintains its relative distance to the user’s 
device. Notice that our error in distance is significantly lower 
in this experiment relative to jj |12. 2| This is because drones 
measure multiple distances as they navigate in the air, which 
helps de-noise measurements and remove outliers (see ^9j. 

Fig. 1 10(b)] depicts a candidate overhead trajectory of the 
drone, captured using the Vicon motion capture system. The 
trajectory reveals that the drone follows the user’s location 
closely, as expected. Observe that at each point in its trajec¬ 
tory, the drone maintains a steady pairwise distance of 1.4 m 
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relative to the device. Finally, Fig. 1 10(c)] depicts a represen¬ 
tative picture of the user that drone took along the way (face 
blurred for anonymity). Notice that the picture was taken at 
the optimal distance of 1.4 m and ensures that the user is at 
the right focus. Note that the Go-Pro uses a wide-angle lens 
which ensures that the user at 1.4 m is fully in-frame. 


13. Conclusion 

This paper presents Chronos, a system that measures 
sub-nanosecond time-of-flight on commercial Wi-Fi radios. 
Chronos leverages these time-of-flight measurements to 
demonstrate device-to-device indoor positioning at state-of- 
the-art accuracy, without third party support. To illustrate 
these capabilities, Chronos enables light-weight personal 
drones to track a user’s location in indoor environments. Be¬ 
yond personal drones, Chronos opens up indoor positioning 
to many new contexts, where pairs of devices interact, e.g., 
gesture-based gaming consoles, finding lost devices, main¬ 
taining robotic formations, etc. 
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